An important factor in determining the success of a new release of software is the degree of compatibility that the new release has with third party applications and hardware. For each error that the new release causes with existing applications and hardware, the release is viewed less and less favorably by software consumers. If the new release causes a significant number of errors, many consumers may forego upgrading to the new release, which impacts the profitability of the new release.
There have been attempts at checking new software releases for potential problems. Some attempts provide dynamic checking and others provide static checking. Dynamic checking checks the executable code as the new software release is running. Static checking checks the source code that will become the executable code of the new release.
When the source code is not very large, a manual process of comparing files may be attempted. However, typically, today, new releases involve a few thousand source code files with each source code file having several lines of code. Therefore, the manual process is not a very useful technique. Some static checkers have automated the process, but have experienced limited success. One such type of automated static checker performs a document compare on source code files in a new release with source code files from a prior release. This type of automated static checker gives many false change indications. For example, if the same code is used in the new release, but is moved within a file or is moved to another file, this type of automated static checker indicates a change in the file or files. Thus, giving a false change error. Other attempts require programmers to annotate the code in order for the static checker to identify potential problems.
Until the present invention, a static checker that works on a large source code base, requires no code annotation, and generates meaningful and useful errors has not been realized.